Extract duplicated snapshot-cap literal in ExceptionProbeManager - #2

Context

This is a bounded JAIPilot companion for the exact PR head a8822169dad29d03a5c6222df9e545c4a1b805cd (mirror of DataDog#12254, which fixes an exception-debugger memory leak from HotSpot's FastThrow/OmitStackTraceInFastThrow optimization by capping captured snapshots per throwable and removing the ThrowableState once its snapshots have been assigned to a span).

Change

In ExceptionProbeManager.ThrowableState#addSnapshot (code added by this PR), the cap value 256 was written twice within 4 lines: once in the size() > 256 guard and once hard-coded into the LOGGER.debug message text ("Too many (256) snapshots..."). Extracted a single private static final int MAX_SNAPSHOTS = 256; field and referenced it from both places (the log message now uses a {} placeholder for the value). This removes a duplicate-literal drift risk without changing the cap value, the rendered log text, or any other behavior.

Why not more

Every other line the PR touches (the Throwable innerMostException plumbing into processSnapshotsAndSetTags, and the new ExceptionProbeManager#removeThrowableState) is a minimal, already-clean fix for the leak/empty-snapshot-list bug fixed by the two upstream commits (15c924f4, a8822169). There is no unused code, no duplicate logic, and no measurable hot path to optimize in this bounded diff, and the two changed files touch no dependency/JDK/framework version, so cleanup, performance, and modernization passes beyond the one accepted edit are not_applicable/already_satisfied.

Verification

• Focused behavior command run unmodified as baseline and candidate: ./gradlew :dd-java-agent:agent-debugger:test --tests "com.datadog.debugger.exception.*" -> 27/27 passed both times, including the PR's own addSnapshotCapsGrowth test that directly locks the 256-item cap-then-stable-size behavior.
• spotlessCheck passes (no formatting drift).
• Full module build/test: ./gradlew :dd-java-agent:agent-debugger:test -> 782/782 tests passed, 0 failures/errors.

Environment note

This cloud sandbox's auto-provisioned Gradle toolchain JDK (Temurin 25, pinned by the repository's gradle/gradle-daemon-jvm.properties) did not trust the sandbox's own TLS-inspecting egress gateway CA, which initially blocked all Gradle dependency/plugin resolution (while curl and the system JDK worked fine). This was resolved by importing the sandbox's already-trusted gateway CA certificates (present in /etc/ssl/certs/ca-certificates.crt, the same bundle SSL_CERT_FILE already points to) into that toolchain JDK's cacerts truststore -- a local environment fix only, not a repository change -- after which the real Gradle build and tests ran and passed as reported above.

Generated by JAIPilot Cloud for #1 from Anthropic session sesn_01R97M2SJtizJZqLCTJGioSx.